Performance really bad



So yes I decided to host with Dreamhost because what Dreamhost offers is exactly what i was looking for.
Shell access(ssh), scp, unlimited domains, etc. Pretty good.

No I have have payed my twe years hosting plan, and I noticed how bad dreamhost actually performs. Slow start. Mysql also seems to be slow.

So I am thing to ask my money back, but I payed with credit card, and I just read that credit card money back is not offered, what now?

Should I stay or should I go???


Well, it’s not universally slow. Have you submitted a support ticket about your problems? What was the response? What is your site? The folks here on the forums always seem happy to check out other people’s sites and provide advice!

Where did you read that? It was my understanding the the 97-day money-back offer was valid for both credit cards and Google Checkout, but not the other options.

It’s up to you. You should do what makes you comfortable.

Use the [color=#CC0000]3DOM50[/color] promo code for 3 extra lifetime domains and $50 off
More Dreamhost coupons here!


I don’t know where you read that, but either it is incorrect, you read it wrong, or you misunderstood it.

According to the DreamHost 97 Day Money-Back Guarantee, using a credit card, or Google Checkout is required in order to get a refund under the terms of that guarantee:

"If you decide - within the first 97 days of your time with us - that DreamHost isn’t for you, we will gladly close your account and refund any payments you’ve made to us within those first 97 days.*

  • Credit card and Google Checkout payments only. Excludes domain registration fees, bandwidth overage charges, and dedicated server payments. Refunds not guaranteed for accounts found to be in violation of DreamHost’s Terms of Service or Anti-Spam policies."

Well, that’s entirely up to you, but you should qualify for a refund if you decide you want to go. :wink:

I like it hear, and have found no performance issues that have been other than temporary in nature, and I’ve hosted here for almost 10 years now … I like it at DreamHost a lot, and would rather work through any temporary performance issues that go with another host that is less flexible and offers less.

I also like doing business with DreamHost, and have found them to be honest, professional, and considerate of my needs while providing outstanding value for my money - hey, YMMV :wink:

Have you contacted tech support and asked them to investigate your performance issues? If not, I’d suggest you try that before making your decision. It could be that a “bad neighbor” on your server is responsible for your performance issues, and your needs might actually be met if DreamHost is able to track them down a curtail their overloading of the server you are sharing.

Of course, DreamHost is not the best choice for everyone - some sites just require more resources (CPU/RAM)than a DreamHost shared account provides, and some sites may benefit from a different MySQL infrastructure.

Fortunately, in your case, you have a choice with the availability of the Money BACK Guarantee … partly because you paid with your credit card. :slight_smile:



Hey hey hey! You were faster! … (but you didn’t have an “entertainment link” in your post!)

“What Lensman said!!” :wink:




It must have been late because you’re right about the credit card refund thing. I remember that I was very tired and I guess my brains interpreted the text wrongly…

And even more stupid, i just found out that i used a very slow internet connection here. I have two wifi connections here, one is a free cable/voip internet connection wich is terrible slow…

Sorry for the fuzz, I need to get get more sleep!!

Problem is that dreamhost offers so much to play and 3:00 am is the resulted bedtime (-;



Issues here are always temporary. I came from a host that used to be excellent but then their issues were chronic and sometimes went on for months to (literally) well over a year (edging toward two). You’re not going to have flawless service with anyone you do business with. So when you make your decisions you need to decide who you think will be best to minimize problems, and fix problems quickly when they do occur. Another consideration is open communication. When something big goes wrong here, DH fesses up. Some other hosts might report downtime but not explain what happened or what they’re going to do to ensure it doesn’t happen again. If DH isn’t reporting a system-wide issue then chances are good that there is something on your site that is mis-configured, some temporary itch on a specific system, or something else that shouldn’t make or break a longer term business decision. You can do a LOT LOT worse than DH. After coming from hosts that I thought were good until they showed signs of consistent flakyness, DH seems to be consistently very good. Think long term and decision should be pretty easy. HTH


I did a one click install of Joomla for my domain. The front page loads in 5 seconds.

What do you think, is 4 to 5 seconds ok?

personaly i was more thinking of try to have the front page be loaded in one second.



The first page of a joomla site can often take that long … depends a lot on the template :wink: . A 'one second" Joomla front page can be done, but it takes a very light template and no content to do that.



In The Netherlands you’re dealing with some amount of latency. Try a ping of your web server to see what turnaround time is. Try tracert to see how many hops you’re making. I got your front page in about a second - no delay at all.

With a one-click install that is oriented toward “one size fits all” the opimization is probably minimal to none.

If your audience is more european then you may want to consider a more local host, or just accept that some local connectivity may be slower than elsewhere. If your audience is generally on this side of the pond then it looks to me like you’re doing OK. The only thing I’d recommend is getting familiar with optimization techniques for Joomla in general, then maybe PHP.ini customizations (careful!) and anything you can do for a MySQL database.


Hi, I have done some performance tests.

The tests;
I have installed the mysql Sakila sample database and ran some queries.

I found that the ‘film’ table did not perform well, It took 7 seconds to get the 1000 records. (SELECT *)
I noticed that when I select less columns the results are faster. If I only select the film_id, its really fast.

This sounds to me that it could be a network problem.

Until now I did not see performance improvements.

My audience is USA but also for another site purely for the Netherlands.

Does dreamhost have servers in Amsterdam?
This slowness it not nice, this forum is even slow, and sometime the site is also very slow, also the webpanel.

Does dreamhost monitor this? Is this acceptable?

I would say it should be fast for both sides of the pond. Electricity goes with the speed of light, so pond or not that should not matter. It just depends on how the traffic from dreamhost comes to Amsterdam.

Her some tracrt’s. First mysite, then Google, and then a dreamhost hosted site of a friend of me…


Traceren van de route naar []
1 * * * Time-out bij opdracht.
2 11 ms 12 ms 10 ms []
3 13 ms 11 ms 13 ms []
4 47 ms 12 ms 13 ms []
5 14 ms 12 ms 13 ms []
6 155 ms 155 ms 155 ms
7 157 ms 156 ms 155 ms []
8 155 ms 157 ms 158 ms []


Traceren van de route naar []
1 * * * Time-out bij opdracht.
2 11 ms 11 ms 11 ms []
3 14 ms 13 ms 13 ms []
4 12 ms 13 ms 13 ms []
5 13 ms 20 ms 13 ms []
6 13 ms 13 ms 13 ms
7 16 ms 17 ms 16 ms
8 16 ms 16 ms 16 ms
9 68 ms 21 ms 20 ms
10 17 ms 18 ms 17 ms []


Traceren van de route naar []
1 * * * Time-out bij opdracht.
2 11 ms 10 ms 11 ms []
3 * * 13 ms []
4 12 ms 13 ms 13 ms []
5 13 ms 13 ms 12 ms []
6 321 ms 197 ms 264 ms
7 157 ms 155 ms 155 ms []


Hi America, I keep having slow performance for my sites. It seems that it is caused by latency of the packets between USA and Amsterdam.

I really like what I get at dreamhost, but the performance issue makes me to choose leaving Dreamhost. I have to do it from here :frowning: I don’t think it will change.

Look at section of my the trace route, when the pond is crossed, the dream goes over…

13 ms 13 ms 12 ms
321 ms 197 ms 264 ms

Latency is my foo now, maybe I should not be dreaming.



200ms-300ms is a bit on the high side, but I can’t really see how it could be disastrous given that latency from the east coast of the US is around 100-150ms and I consider my performance “fast”…

Use the [color=#CC0000]3DOM50[/color] promo code for 3 extra lifetime domains and $50 off
More Dreamhost coupons here!


Hi Lensman,

Well, the tracert shows 200 / 300 ms, but the effect on the browser is that I sometimes have to wait 4 to 6 seconds to load an empty joomla / wordpress site.

But the strange thing is that it is not always like that. Sometimes the site loads within a second here.

So I am not sure now where the delay comes from…


Have you run firebug and yslow to determine what part of the Joomla! front page is taking a while? Is it the images? Is the number of requests? Certain modules that take a long time?

Use the [color=#CC0000]3DOM50[/color] promo code for 3 extra lifetime domains and $50 off
More Dreamhost coupons here!


Yes I tried that, nut because Joomla was totally stripped, it was not the assets I think. I have something else interesting , read on!

I have tested the performance of my dreamhost powered site. It was terrible slow, but i have found something interesting.
I suspected that the slow performance was due to the mysql server. And my first test results reveal that this is indeed the case.

I installed phpbb now, with SQLITE instead of MySql and I can clearly feel the difference. The difference in every click is around 3 seconds.

SQLITE is really fast! and sufficient for a bulleting board system.

The response now here in Europe is around 1 second, wich I think is acceptable.

So what do you think of my findings? interesting right?

Let me know…


I would be worried about scaling on a SQLite backed phpBB. Because of the way SQLite works, it’s bound to be very efficient on a small forum which isn’t needing to deal with very many users. As the size and usage load of the forum grows, though, I would expect the speed gains you’re seeing to quickly evaporate.

The reason for the scaling problem is due simply to the way SQLite works. Like all other databases, it needs to take care to ensure the integrity of the data that it’s being asked to store and retrieve. That means, among other things, that it needs to prevent concurrent writes to the same piece of data and to prevent you from reading data that’s in the process of being overwritten. To do this, all databases have a mechanism that allows them to lock a particular piece of data during write operations to ensure that there is only one writer at a time, and during read operations to ensure that nobody can start writing until everyone is done reading.

In order to produce these locks, all potential readers and writers need to ask permission from a single controller that will decide whether or not there are locks available. In the case of MySQL and other database servers, the controller is the server itself, and it can look into the database all the way down to the row level in order to hand out locks. The result is that you’re locking only a very small portion of the database at a time, with the (normally safe) assumption being that not everyone is going to want exactly the same piece of data at exactly the same time. In the case of SQLite, the controller is the filesystem, which can only look at data with a granularity of a whole file at a time. Because SQLite databases are single files, that means that you’re creating locks on the entire database. With a lot of users, that’s a lot of waiting for locks.

To make matters worse, phpBB, like most forum software, does a lot of writing. Most obviously, you have people creating accounts, starting threads, and making posts. Less obviously, phpBB uses the database to keep track of user session information; effectively, it writes a little piece of data everytime a user enters a new forum or opens a new thread. Thread views get counted and stored in the database, too.

Now, if your forum is small, and likely to stay that way, it’s entirely possible that SQLite will work well for you. It certainly has a lot less overhead than what it takes to connect to MySQL and send queries and get results over the network, with the result being exactly what you’ve described.

But I guess what I’m saying is, “Administrator beware.”


Thanks for commenting.

The target is a small phpbb system (100 users max or so), and it will be a closed system, so the use of Sqlite could work for me I think. But you are right about the filelocking problem, that could surely create problem. And also it only would make sense to use if it has an increased performance. I just compared the two versions, and today they seem to perform equal, or near equal.

Now the problem with the delay is still there, and I am still not sure where the problem lies. Could it be the Filer that is used?

I was told by support that all the servers including the Mysql server use a network attached storage called the Filer.

Now thinking of the situation where all the files must be transmitted over network cables, using the switches. With this I am curious how this system works. What equipment is in use, and how is it all connected? Could it be that some improvents can be made here?

Or is it just that I request the pages from Europe and that those traveling packets are delayed at foreign airport security checks? why the hack is it so slow?

Below is a copy of a post where is described that Sqlite could work well on a single server with reasonable traffic.

Re: [sqlite] SQLite for large bulletin board systems?
D. Richard Hipp
Fri, 27 Aug 2004 14:30:47 -0700

Larry Kubin wrote:
Hello everyone. I am interested in creating a PHP/SQLite powered
bulletin board system similar to phpBB. However, I have read that
SQLite is best suited for applications that are mainly read-only
(because it locks the database during writes). Do you think a SQLite
powered bulletin board is a bad idea? How would I go about handling
the case where two users are trying to write to the database

The CVSTrac system on is backed by an SQLite
database (of course). Every single hit does a write to the
database. It gets 20K hits/day from 2K distinct IPs and runs
on the equivalent of a 150MHz machine with no problems at all.
It could easily handle more traffic. On a faster machine, it
could handle lots more traffic.

I’ve run tests on a workstation where an SQLite-backed website
was handling 10 to 20 hits per second (simulated load).

Use the busy handler on SQLite so that if one thread is writing,
all other threads simply wait their turn.

The trick is not to linger of your writes. Decide what you want
to write into the database, start the transaction, make your
update, and commit. You can make a big change in 10 or 20
milliseconds. What you should avoid doing is starting the
transaction, then doing a bunch of slow computations, then
writing the results and committing. Compute the results first,
before you start the transaction, so that your lock window is small.

If you want to accumulate a lot of results over time and store
them all atomically, write the results initially into a TEMP
table. Then copy the TEMP table contents into the main database
in a single (atomic) operation. Writing to a TEMP table does not
lock the database.

A good rule of thumb is that if your website is small enough
that it can be run off of a single webserver and you do not
need a load-sharing arrangement, then SQLite will probably meet
your needs. If you website traffic gets to be so much that
you are thinking about offloading the database onto a separate
processor or splitting the load between two or more machines,
then you should probably use a client/server database instead.

The best design would be to make the application generic so
that it could use either SQLite or a client/server database.
Then smaller sites could use SQLite and take advantage of
the reduce management and overhead it provides while larger
sites could use a client/server database for scalability.

D. Richard Hipp – [EMAIL PROTECTED] – 704.948.4565


Dreamhost uses a variety of different NAS devices to provide storage for their systems, along with, in some cases, direct attached storage for their database servers.

In the datacenter environment, the oft-imagined latency and transfer times people imagine are a result of the network transfer aren’t as much of a factor as people imagine them to be. Other factors affecting performance are as big of a factor.

Network latency associated with NAS over gigabit ethernet is measured in microseconds - maybe 20-50us at the application level. Compare this with disk drive latency measured at around 5-7ms for typical enterprise drives.

Looking at transfer rates, the fastest drives provide 100MB/sec. Utilizing jumbo frames, one gets around 600Mbit/sec or 75MB/sec over gigabit ethernet. At any rate, the rates are comparable - though you could probably design a high performance direct-attached raided storage system that could outperform NAS.

In addition, the load associated with web servers provides a demand almost perfect for NAS. Think about it - let’s say your system is under load and has 10 simultaneous page requests to handle. For each of these requests, there’s one or more files to retrieve, a database query or two to issue, and some calculations to do. Since the file retrieval and database query are “assigned” to the file server and the database server to handle, the web server can focus on the “calculations” (which mostly involve string manipulation, I’d guess).

At any rate, I’d be interested to hear about how sqlite works out for you. In addition to the issues listed by the other folks, I’d be interested to hear whether sqlite resource utilization scales well as the database grows. Memory is a precious resource on web servers and it’s not like it can be fully managed by the database server itself like it can be when you’re dealing with a dedicated database server.

Use the [color=#CC0000]3DOM50[/color] promo code for 3 extra lifetime domains and $50 off
More Dreamhost coupons here!