MiniVend Akopia Services

[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date ][Minivend by thread ]

Re: Server load,bad robots and server config



******    message to minivend-users from "William Rothbauer" <madpages@madpages.com>     ******

This issue is of particular interest to me.  Mike's email has brought me to
ask several questions.

1) I use DB_File for my databases.  Would I be better off using GDBM?

2) Correct me if I'm wrong on this, if I were to set MINIVEND_NODBM,
Minivend would use in memory databases, which is a bad thing ... isn't it.

3) I've asked this before, but I state it here again.  I've noticed that if
a user session saves to much info to the session.db, the session.db grows
very quickly, even when there isn't a significant amount of new info sent to
the database.  Is this an issue with DB_File that can be corrected by
setting MINIVEND_NODBM or switching the gdbm.

4) Finally, I see the "Hammered Session" error three or four times a day in
my error log, does this indicate that my system isn't handling the traffic
or is it my Minivend set-up?

Regards,

Bill Rothbauer


Mike wrote:

There is something else going on; you need to optimize your database
performance somehow and I would double-check the FAQ items. If you haven't
run expireall -r then your session database is probably getting big.

But there are lots of other potential problems, one of which is "hotspots"
on the session database when all your hits are in one catalog. This
is particularly a problem with DB_File. There I recommend running with
MINIVEND_NODBM and using the file-based sessions. With a little trouble,
it is even possible to do that and still have access to GDBM or DB_File
databases. Just put "require Vend::Table::GDBM;" somewhere at the top
of the Data.pm module and run with MINIVEND_NODBM set in your environment.
Then you can explicitly specify in catalog.cfg

Database products products.asc TAB
Database products GDBM         1

and it should use GDBM. (This works for MV3.12 only.)

As I said, it could be many things. And if you think MV is alone in
that regard, take a look at the many articles in technical publications
that deal with optimizing database performance. It isn't always easy. 8-)

--
Mike Heins                          http://www.minivend.com/  ___
                                    Internet Robotics        |_ _|____
                                    131 Willow Lane, Floor 2  | ||  _ \
It's a little-known fact            Oxford, OH  45056         | || |_) |
that the Y1K problem caused         <mikeh@minivend.com>     |___|  _ <
the Dark Ages. -- unknown           513.523.7621 FAX 7501        |_| \_\
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to
Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list


-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list


Search for: Match: Format: Sort by: